Publicly available symmetric encryption algorithms (e.g., Triple DES, RC4, AES, etc.) are widely accepted as providing secure communications between any two parties who share a secret symmetric encryption key, hereinafter referred to as a “SecretKey.” This SecretKey, known only to the two parties, may be used to create encryption sessions which allow the two parties to communicate securely across a public network with the assurance that no unauthorized third party will easily be able to eaves-drop on the plaintext protected by the encrypted communications. The stronger the encryption algorithm, the more difficult the challenge becomes to correctly decrypt into plaintext any ciphertext being exchanged by the two parties. An advantage of symmetric encryption is that each party is assured of the cryptographic identity of the other party by the successful decryption of received ciphertext into meaningful plaintext, provided that both parties and the protocols employed adequately protect the SecretKey from disclosure.
However, it is widely accepted that using only symmetric cryptography to provide secure communications between any two parties within a large community of registered members is impractical. This belief is based upon the well-documented mathematics used to calculate the number of different SecretKeys that must be generated, distributed and managed to support the entire community. In accepted practice, each member of a registered community must share a different SecretKey with every other member, the total number of SecretKeys being determined by the formula: (N×(N−1))/2, where N is the number of members in the community. Thus, for a community of 1,000 members, exactly 499,500 different SecretKeys would be required for each member to share a different SecretKey with every other member. Of course, this is the maximum number of required SecretKeys since all members in the community may not wish to communicate securely with all other members. Still, the key generation, management, and distribution logistics for managing and maintaining SecretKeys even for subsets of members within such a relatively small community is daunting, requiring complex security mechanisms to assure each member that no SecretKey has been disclosed to anyone other than the two parties sharing the key. For larger communities having millions of members, the potential number of SecretKeys is staggering. Such logistical problems led to the adoption of protocols (e.g. Transport Layer Security) that employ asymmetric encryption algorithms to secure internet communications.
In general, asymmetric encryption algorithms employ public-key/private-key pairs. Messages encrypted using the public-key may only be easily decrypted using the paired private-key. Clients wishing to establish a secure connection with a particular host server are supplied by the host with a public-key with which to encrypt initial connection-request messages. The host server is then able to use the private-key to decrypt such messages that typically contain session-specific information such as a temporary SecretKey, which may then be used to initialize a symmetric encryption algorithm to encrypt subsequent messages. However, assurances to either party as to the certified identity of the other party must be accomplished independently.
For client identification and authentication, secure host servers have adopted the use of usernames and passwords. However, password cracking has been developed into a science by the hacker community, making simple passwords inadequate. In consequence, more and more complex password constructs are now required, resulting in the practice of users having the same password for multiple sites or maintaining password lists near their computers. Both practices create serious security vulnerabilities that may be exploited. Also, a lost or forgotten password has now become a frequently recurring problem that must be dealt with using additional security measures.
For host identification and authentication, a trusted third party (certification authority) is required to assure a client that a published public-key is truly associated with the identity of a specific secure host website. Phishing sites with website displays similar to legitimate sites have been developed and successfully employed to steal username/password combinations from unsuspecting users who have been directed to these sites by redirection clicks within emails or by icons on illicit websites. Few users check to ensure that their web browser is displaying the secure lock icon or to carefully examine the website address displayed by the browser to assure that it is correct, particularly now that most website addresses have become so complex. As a counter-measure, some secure servers have adopted the practice of associating a client-selected icon with the username of each client. This icon is displayed on the password entry screen to reassure the client of the identity of the host. Many such adopted solutions are site-specific. Viewed as a whole, they impose a hodge-podge of security measures that inadequately address the security issue of dual-authentication while irritating and frustrating the user community. None of these measures approach the level of security offered by a secure protocol that uses only symmetric encryption.
Kerberos, a publicly available network authentication protocol developed at the Massachusetts Institute of Technology, is one such protocol that uses only symmetric encryption. The Kerberos protocol, based upon the Needham-Schroeder symmetric encryption protocol, specifies the content of specific data packets and a sequence of data packet exchanges by the participating parties to establish a secure session using only symmetric encryption. The Kerberos protocol improves upon Needham-Schroeder by inclusion of a timestamp used to defeat packet replay attacks. The foundation of the Kerberos protocol security is the “Authentication Server,” a trusted third party having a database containing a SecretKey for every registered user in the community. In general, using the appropriate SecretKeys within its database, the Authentication Server authenticates each of the two parties wishing to establish a secure session on the network, securely distributing a temporary SecretKey to both parties within encrypted message data packets. These data packets are encrypted using an encryption session initialized with the SecretKey shared by the Authentication Server with each party to encrypt that party's data packet. One practical drawback to this approach is the threat represented by insider access to the SecretKey database of the Authentication Server. Anyone illicitly obtaining the SecretKey of a single user would be able to successfully masquerade as that user. Of course, the compromise of the entire SecretKey database of an Authentication Server would wreak havoc, as demonstrated by the recent security breaches affecting well-known and widely used security systems (e.g., the compromise of SecurID keys of RSA Security in March 2011).